home *** CD-ROM | disk | FTP | other *** search
/ The Programmer Disk / The Programmer Disk (Microforum).iso / xpro / c2 / pro24 / read.me < prev    next >
Text File  |  1988-06-21  |  4KB  |  93 lines
  1. Hi!
  2.  
  3. These routines are the result of many nights of tinkering.
  4.  
  5. They've been hacked over and over, so they're not especially easy to
  6. follow, but (for the most part,) they work OK, and can be used to add
  7. .PCX file I/O and display facilities to your graphics project. 
  8.  
  9. Incidentally, if you really need something like this for business
  10. purposes, buy a real package! This is NOT a "Serious Graphics System"
  11. (SGS?) I originally put it together in an effort to get schematics into
  12. Ventura Publisher.  The vgr_fill() routine was written as part of a
  13. (crazy) pipe dream: to try and build a bigger-than-24-point HPLJ
  14. character set... 
  15.  
  16. Do as you wish with this stuff, It's free for the taking, with only one
  17. restriction: You should consider this to be "Post Ware," ie: if you find
  18. yourself using it, grant me a 'byline' and send a post card!
  19.  
  20. The file DOC.TXT is a Ventura Publisher source containing the
  21. documentation for these routines. 
  22.  
  23.  
  24. If you got your hands on a version of this .ARC dated prior to June
  25. 21st, 1988:
  26.  
  27.     (1) There was a bug in pcx_read_pic() that was introduced when I
  28. removed the call to my bufread() library function and replaced it with
  29. the standard I/O fread() call - the comparison should be against a count
  30. of 1 instead of a structure size of sizeof(*ph). 
  31.  
  32.     (2) The declaration "int (*vgr_func[14])();" in vgr.h should read
  33. "int (*vgr_func[15])();". 
  34.  
  35.     (3) The pcx_free_pic() function has two obviously silly
  36. "debugging" lines in it.  You'll find them real quick when you try to
  37. use that function! (it puts you back in text mode and tells you that
  38. you're probably out of memory...  true if it's called from a function
  39. that had a memory allocation problem, but otherwise not true...)
  40.  
  41. The file VGRX is new.  It's got a routine in it that was made from part
  42. of main() in PCX.C; the function of which is to figure out what video
  43. board is in use, and set up some variables that make using the VGR
  44. routines easier. 
  45.  
  46. vgr_setup() takes a pointer to char called specifier.  If the
  47. "specifier" pointer is non-null, it's assumed to point to a string which
  48. is used to force the routine to assume a particular board.  This may
  49. turn out to be handy with non-cga/ega/herc graphic boards, and
  50. especially in those cases where the board detect logic fails.  If the
  51. pointer is NULL, then it's ignored and the routine uses vgr_get_board()
  52. to try to figure out what board you've got.  See the listing to get the
  53. names of all the global variables in vgr.h that're affected by
  54. vgr_setup(). Note also that there's no way of returning a board type 
  55. number for the CGA 320x200x4 mode, so the kludge solution was to set
  56. the type number to 9. I would have just added an extra #define for a board
  57. of that type, but I didn't like the idea of the added confusion with the
  58. mode number. (in the mean time, it's gotten confusing...)
  59.  
  60. Note that your program must allocate all globals by #DEFINEing ALLOCATE
  61. before #including "vgr.h"! Otherwise, you'll get undefined globals at
  62. link time.
  63.  
  64.  
  65. The PCXSHOW program seems to work fine, it's only been tested on an ATI
  66. EGA Wonder, which doesn't seem to be 100% compatible.  It just dumps the
  67. contents of the picture into the VRAM, so some pictures won't look
  68. exactly like they did when they were generated, but it does give a good
  69. idea of what the picture is about.  (Sorry; I had planned on writing a
  70. picture format converter - it wouldn't be difficult, just pcx_init_pic()
  71. two picture structs for the two different formats, then "get" a pixel
  72. from one and "set" it into another - just too many higher priority items
  73. on the back burner as it is...)
  74.  
  75. The IBMTIMER.c module is from my lib.  I figured it's ok to add to this
  76. .ARC since it's small enough and doesn't call in any other modules. 
  77.  
  78. Another note: I still haven't tried some of the palette functions, so
  79. they're still not to be considered reliable.  (Most of the EGA stuff
  80. should be OK, the CGA stuff was never tested.)
  81.  
  82.  
  83. I hope this'll be handy for you!
  84.  
  85.  
  86. Sam Azer
  87. AzerTech Computer Systems
  88. 2095 Patricia Ave, #1
  89. Montreal, Quebec, Canada
  90. H4B 1Y7
  91.  
  92.  
  93.